1. Field of the Invention
This invention relates to computer systems, and more particularly to inter-nodal communications in a cluster environment.
2. Description of the Related Art
Distributed applications are often implemented as part of commercial and non-commercial business solutions for an enterprise. For example, a company may leverage the use of an enterprise application that includes various databases distributed across multiple computers. Applications of this type, which support E-commerce, typically support hundreds or thousands of sessions simultaneously during periods of peak utilization. For scalability and fault tolerance, the servers running such applications may be clustered.
FIG. 1 illustrates a networked computer system including a cluster 100, according to prior art. Clients 110 may be coupled to cluster 100 through network 120. Clients 110 may initiate sessions with application components running on nodes 140. Load balancer 130 may distribute session requests from clients 100 to nodes 140 to “balance” the total workload among the servers. In some cases, load balancing may amount to nothing more than round-robin assignment of new sessions to cluster members. In other cases, load balancer 130 may have access to data concerning the current workload of each node 140. When a new session request is received, load balancer 130 may use this data to determine which server has the “lightest” workload and assign the new session to that node. Regardless of the distribution algorithm used by the load balancer 130, the capacity of the application component(s) running on the nodes 140 of the cluster is greater that if it were limited to only a single node, and most architectures for cluster 100 include scalability to allow for increasing capacity by adding additional nodes 140 to the cluster.
Another desirable characteristic of an application component(s) executing on a server cluster is high availability. For an application component running in a non-clustered environment, the failure of its server makes the component unavailable until the server is repaired or replaced. This loss of service may be very undesirable for an enterprise, particularly if the function being performed by the application component is, for example, registering orders for products or services. If the application component is executing on a cluster, one or more nodes 140 within the cluster can fail, and the application may continue to provide service on the remaining active servers, although at a reduced capacity. This attribute of a clustered server environment is called “failover”, and it can be implemented in a variety of ways. In some cases, the load balancer 130 may determine that a given node 140 has failed and simply not assign any further work to that node. This insures that new requests will receive service, but does nothing for work that was in-process on the failed server.
Many cluster architectures have been formulated to address the need for graceful failover of cluster members to attempt to minimize the impact of server failure on end users. For a failover to be truly graceful, it should be completely transparent to the client. In most cases, graceful failover within a cluster requires the nodes 140 to be “cluster-aware” to the point of being able to detect the failure of fellow cluster members, and in some cases each server needs to be able to resume the processing of jobs that were executing on the failed server at the time it failed. The increase in complexity for each node 140 to support this level of graceful failover may be quite large in terms of the design, verification, and maintenance of the additional functionality.
The cluster-awareness described above as a basis for such functionality as load balancing and failover, may require an inter-nodal cluster communication channel. For example, to support load balancing and/or failover, each node may require current information on cluster membership including existing nodes that have failed and/or new nodes that have joined the cluster. When a cluster node fails, load-balancing functions such as those described previously may need to be aware of the failure so as not to send new requests to the failed node. Likewise, a failed node should be removed from the list of candidates for failover node for all other nodes.
The architecture of the cluster communication channel may take various forms from daisy chained, to star coupled, to rings, and bussed. Additionally, various communication protocols may be implemented for use on multiple network topologies. In some configurations, each node may gather cluster membership information for itself, while in others one central node may determine cluster membership and disseminate a list to other members.